Using a description language to provide a user interface presentation

ABSTRACT

A system is described for building a dialog-related user interface presentation. The system includes description language content (such as markup language content) which describes different aspects of the dialog-related user interface presentation. The system also includes generic resource content for providing various general purpose user interface resources that can be used in different dialog-related user interface presentations. The system provides the specific dialog-related user interface presentation by combining the description language content and the generic resource content. In other words, the description language content effectively tailors the generic resource content to provide the specific dialog-related user interface presentation. One aspect of the description language content defines the type of the dialog-related user interface presentation that is to be deployed. Another aspect of the description language content describes a manner of arranging (or otherwise deploying) parts of the dialog-related user interface presentation. Another aspect of the description language content defines default content that is provided by the dialog-related user interface presentation. Another aspect of the description language content describes validation rules used to validate information input by a user via the dialog-related user interface presentation.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is related to commonly assigned U.S. Ser. No. 10/______(Attorney Docket No. MS1-2266US/310540.01) filed on the same date as thepresent application, entitled “USING A DESCRIPTION LANGUAGE TO BUILD AMANAGEMENT SYSTEM,” naming Jeffrey B. Phillips, Jie Liu, and Kenneth A.Argo as inventors. This related application is incorporated herein byreference in its entirely.

TECHNICAL FIELD

This subject matter relates to strategies for providing a user interfacepresentation. In a more particular implementation, this subject matterrelates to strategies for providing a user interface presentation withinthe context of a management system.

BACKGROUND

Management systems allow users to manage target functionality. “Targetfunctionality” can comprise an application or applications, e.g., asimplemented by one or more computer systems, which are the “target” ofthe management system's management operations. One well known managementsystem uses the Microsoft Management Console (MMC), provided byMicrosoft Corporation of Redmond, Wash. Detailed information regardingthe MMC management system is provided by a number of sources, such asMicrosoft Corporation's MSDN online library site.

Broadly stated, a typical management system provides a container (amanagement console) which binds together a collection of tools formanaging different aspects of target functionality. Accordingly, thecharacteristics of a management system may differ depending on the typesof tools that the management system incorporates. In a typical role, themanagement system allows a user to query the target functionality toextract management information from the target functionality. Themanagement system then presents the retrieved management information tothe user and allows the user to interact with the managementinformation. For instance, the user can use the management system tomanage the configuration of some aspect of the target functionality. Inthis role, the management system queries the target functionality toextract configuration information from one or more configurationdatabases maintained by the target functionality. The management systemthen allows the user to perform various actions that affect theconfiguration information, which thereby affects the configuration ofthe target functionality.

FIG. 1 shows salient features of a known system 100 that uses amanagement system 102 to govern the operation of target functionality104. As described above, the management system 102 provides a shell orcontainer which aggregates different tools. Code resources 106 providethe functionality which implements the management system 102.

The management system 102 provides an integrated user interfacepresentation that allows a user 108 to conveniently interact with themanagement system 102's tools. Namely, the user 108 can interact withthe management system 102 via a series of user interface presentations110 provided on a display device 112 (such as a CRT device, an LCDdevice, etc.), in conjunction with an input mechanism 114 (such as akeyboard, a touch screen, a mouse-type pointing device, a joystick, andso forth).

The target functionality 104 with which the management system 102interacts can be implemented using a standalone computer unit (e.g., apersonal computer workstation), a system that comprises plural computerunits and associated databases (such as a server system and associateddatabases), or some other functionality. In any event, the targetfunctionality 104 can comprise one or more management stores 116. Themanagement stores 116 store management information which governs theoperation of one or more applications 118 implemented by the targetfunctionality 104. For example, the management information cancorrespond to configuration information that pertains to varioussettings, security-related information, etc. that govern the operationof one or more applications 118.

In operation, the management system 102 functions by: (1) querying themanagement stores 116 to determine the management information (e.g.,configuration information) stored therein; (2) retrieving the managementinformation and presenting it to the user 108 via the one or more userinterface presentations 110; and (3) allowing the user 108 to interactwith the management information (which enables the user 108 to modifythe management information stored in the management stores 116). As tothe first of these enumerated tasks, the system 100 provides retrievalfunctionality 120 which allows the user 108 to query the managementstores 116 and extract information from these stores 116. In anexemplary environment that uses a Windows™ operating system, theretrieval functionality 120 can rely on Windows™ ManagementInstrumentation (WMI) technology. Alternatively, or in addition, theretrieval functionality 120 can rely on, in whole or in part,SQL-related technology, Active Directory technology, and so forth.

The user interface presentations 110 provided by the management system102 can use different strategies for presenting management informationto the user 108 and for allowing the user 108 to interact with thatinformation. FIGS. 2-4 provide representative examples of user interfacepresentations 110 based on the UI paradigm employed by MicrosoftCorporation's MMC management console. Referring first to FIG. 2, a mainuser interface presentation 200 includes two panes. A so-called scopepane 202 establishes the “scope of management” of the management system.Namely, the scope specifies the boundaries that define where theconfiguration information originates and the aspects of the system thatare managed by changes in the configuration information. For example, amanagement system directed to the configuration of an operating systemmight specify a root of “System,” and, the System scope can allow a userto configure a disk (defining another scope in its own right), and soforth. FIG. 2 shows that the scope pane 202 includes a plurality ofnodes arranged in a tree-like hierarchical relationship. The topmostnode in the tree defines a root node. Nodes that depend on the root nodedefine child nodes. Based on this paradigm, the user 108 can organizetools into categories based on the commonality of different groups oftools, and so forth. The management system 102 can represent each nodein the scope pane 202 using textual information and/or an image icon.

The user 108 can expand any parent node in the tree (represented by aconventional plus sign “+”) to reveal its child node contents. Toperform this function, the management system 102 may access informationto determine the child nodes associated with a parent node selected bythe user 108. In this particular case, the user 108 has expanded an“event viewer” tool node 206, to reveal different categories of eventsthat can be perused by the user 108 (e.g., application events, securityevents, and system events).

A result pane 204 (also commonly referred to as a detail pane) providesmore detail regarding an identified node in the scope pane 202. Forexample, in the example of FIG. 2, the user 108 has selected a node 208corresponding to a tool that provides system events. Upon selecting thisnode 208, the management system 102 responds by presenting detailpertinent to this node 208, which, in this case, corresponds toplurality of system events. The table-type or list-type presentationshown in the result pane 204 is merely one illustrative example; othertools can invoke other kinds of user interface presentations to revealmanagement information.

FIG. 3 shows one mechanism that allows the user 108 to interact with themain user interface presentation 200. Namely, the management system 102can be configured such that, when the user 108 activates a particularnode, the management system 102 presents a context menu associated withthe activated node. In the example of FIG. 3, the user 108 hasright-clicked on the system node 208. This prompts the management system102 to present an associated context menu 302. As shown, the contextmenu 302 presents a number of options which allow the user 108 tointeract with the management system 102. Selection of one or moreoptions in the context menu 302 may invoke respective submenus, as inthe case where the user 108 selects a “view” option, which prompts themanagement system 102 to present a submenu 304 relating to the viewtopic. In the context of a configuration-related application, thecontext menu options can permit the user 108 to define or modifyconfiguration information which will govern the operation of the targetfunctionality 104.

The main user interface presentation 200 may also serve as a portal forseveral other kinds of supplemental user interface presentations thatwork in conjunction with the main user interface presentation 200.Consider the example of FIG. 4. Here, the user 108 has clicked on aparticular entry 402 in the result pane 204. In this particular example,the user 108's action prompts the management system 102 to display asupplemental user interface presentation 404 that provides moreinformation regarding the selected entry 404. The particular type of thesupplemental user interface presentation 404 shown in FIG. 4 is merelyillustrative. Other management systems can invoke user interfacepresentations having multiple tabbed pages (where the user 108 canselect any page in any order in one of these presentations by activatingits associated tab). Still other management systems can invokewizard-type user interface presentation (where the user 108 isrestricted to interacting with the pages of one of these presentationsin a predefined order). Moreover, the illustrative supplemental userinterface presentation 404 shown in FIG. 4 merely displays informationregarding the selected entry 402. But other supplemental user interfacepresentations (not shown) can allow the user 108 to enter informationinto the management system 102, e.g., via one or more appropriatelyconfigured dialog boxes. In the context of a configuration application,the user 108 can use these supplemental user interface presentations toenter information used to modify information stored in a configurationdatabase. To facilitate discussion, all such supplemental user interfacepresentations are referred to herein as “dialog-related user interfacepresentations.”

Returning to FIG. 1, as mentioned, the management system 102 can rely ona collection of resources 106 to provide the logic which implementsdifferent management system applications. In actual practice, aprogrammer can go about developing code for a particular managementsystem application by separately providing code that implements eachnode of the application. For each node, this code can implement dataretrieval tasks, data presentation tasks, user interaction-relatedtasks, and so forth. A programmer can create other resources to providethe type of dialog-related user interface presentations shown in FIG. 4.

In conventional practice, the code developed to implement differentmanagement system applications represents independent logic. Forexample, at runtime, a management system application X can beimplemented by a first collection of code, while a management systemapplication Y can be implemented by a second collection of code, wherethe first collection of code is independent and autonomous from thesecond collection of code. As in any programming context, it is truethat a programmer can rely on common building blocks to developdifferent applications. But the programmer nevertheless goes about thetask of developing the code for each application on an individual basis,manually integrating and adapting any common code modules into eachapplication on an ad hoc basis so that these modules properly interactwith the rest of the application.

The same design philosophy applies to the creation of dialog-relateduser interface presentations. Different dialog-related user interfacepresentations (such as different wizard-type presentations) representindependent and autonomous UI resources. A programmer may draw fromcommon building blocks in constructing dialog-related user interfacepresentations. Nevertheless, the programmer otherwise goes about thetask of developing each dialog-related user interface presentation on anindividual basis in the manner described above, e.g., by manuallyintegrating and adapting common UI resources into each uniquedialog-related presentation on an ad hoc basis.

As recognized by the present inventors, the above-described approach towriting code and developing dialog-related user interface presentationshas several drawbacks. First, the above-described approach istime-consuming, perhaps requiring a week or more to write the code for asingle node. Second, the above-described approach may provide managementsystem code and associated dialog-related user interface presentationswhich lack uniformity from one application to the next; this, in turn,may make it more difficult to understand the code, and hence to debugand/or upgrade it. Third, the above-described approach implements amanagement system application at runtime using a large amount of codethat is specifically adapted to work with only that application (therebeing no sharing of code among different management systemapplications). This results in various storage-related andperformance-related inefficiencies. The above-described approach todeveloping dialog-related user interface presentations has similardrawbacks.

For at least the above-identified reasons, there is an exemplary needfor more satisfactory strategies for building management systems,including dialog-related user interface presentations used to interactwith the management systems (as well as other applications).

SUMMARY

According to one exemplary implementation, a system is described forproviding a user interface application. The system comprises makes useof description language content, which includes at least: (a) firstdescription language content which governs a type of the user interfacepresentation that is being deployed; (b) second description languagecontent which governs a manner of arranging multiple parts of the userinterface presentation; (c) third description language content whichgoverns whether parts of the user interface presentation are enabled ordisabled; (d) fourth description language content which governs defaultinformation which is presented in the user interface presentation; and(e) fifth description language content which governs a manner in whichinformation input by a user into the user interface presentation isvalidated. The system also comprises generic resource content forproviding at least one resource used to construct the user interfacepresentation. The system also comprises functionality for providing theuser interface presentation by combining the description languagecontent and the generic resource content, wherein the descriptionlanguage content tailors the generic resource content to provide theuser interface presentation.

Additional exemplary implementations are described in the following.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an exemplary system that employs a known management system.

FIGS. 2-4 show exemplary user interface presentations that can beprovided by the known management system of FIG. 1.

FIG. 5 shows an exemplary system that employs a description languageenabled management system according to the present invention.

FIG. 6 provides another exemplary depiction of the management system ofFIG. 5.

FIG. 7 shows a collection of nodes that can be implemented by themanagement system of FIG. 5, particularly illustrating the types ofdescription language content items that can be provided for each node inthe collection.

FIGS. 8 and 9 show exemplary strategies for adapting a master schema anda master user interface (UI) template for use in different local anduser environments.

FIG. 10 shows an exemplary procedure for creating the management systemof FIG. 5.

FIG. 11 shows an exemplary procedure that explains the operation of themanagement system constructed in FIG. 10.

FIG. 12 shows an exemplary computer environment for implementing aspectsof the management system of FIG. 5.

FIGS. 13-25 set forth an example of one management system constructedbased on the principles set forth in FIGS. 5-12.

The same numbers are used throughout the disclosure and figures toreference like components and features. Series 100 numbers refer tofeatures originally found in FIG. 1, series 200 numbers refer tofeatures originally found in FIG. 2, series 300 numbers refer tofeatures originally found in FIG. 3, and so on.

DETAILED DESCRIPTION

According to one exemplary implementation, the following descriptionsets forth functionality and corresponding procedures for building anddeploying a management system. The management system providesdescription language content (such as markup language content) whichdescribes different aspects of the management system in a declarativemanner. The management system also includes generic resource content forperforming various general purpose tasks that can be applied todifferent applications of the management system. The management systemprovides a specific management-related service by combining thedescription language content with the generic resource content. In otherwords, the description language content effectively tailors the genericcode content to provide the management-related service. One aspect ofthe description language content governs a manner of populatingmanagement information to be presented by the management system. Anotheraspect of the description language content governs a manner ofdisplaying the retrieved management information to a user. Anotheraspect of the description language content governs a manner whereby theuser can interact with displayed management information.

According to another exemplary aspect, this disclosure also sets forth asystem for building a dialog-related user interface presentation. Thedialog-related user interface presentation can be employed in theabove-described management system, but is not limited to thisenvironment. The system includes description language content (such asmarkup language content) which describes different aspects of thedialog-related user interface presentation. The system also includesgeneric resource content for providing various general purpose userinterface resources that can be used in different dialog-related userinterface presentations. The system provides the specific dialog-relateduser interface presentation by combining the description languagecontent and the generic resource content. In other words, thedescription language content effectively tailors the generic resourcecontent to provide the specific dialog-related user interfacepresentation. One aspect of the description language content defines thetype of the dialog-related user interface presentation that is to bedeployed. Another aspect of the description language content describes amanner of arranging (or otherwise deploying) parts of the dialog-relateduser interface presentation. Another aspect of the description languagecontent defines default content that is provided by the dialog-relateduser interface presentation. Another aspect of the description languagecontent describes validation rules used to validate information input bya user via the dialog-related user interface presentation.

The systems set forth herein have a number of advantages over the knownapproaches described in the Background section. For example, the systemsset forth herein implement management functionality (and associateddialog-related user interface presentations) in a more efficient andconvenient manner than known approaches. Namely, the systems describedherein allow a user to construct management functionality by simplydefining the features of this functionality in a declarative manner,that is, by writing markup code which defines the desired features. Thishas the effect of implementing the management functionality withoutrequiring onerous and time-consuming construction of the complex code“from scratch” (as is in the case in conventional approaches). Thestrategies described herein also reduce the amount of code that isrequired to implement the management functionality, as each applicationof the management system draws from a common library of genericresources at runtime without having to duplicate the code for eachrespective application.

Additional features and attendant benefits of the strategies will be setforth in this description.

As to terminology, the term the “management system” refers to any systemthat allows a user to inspect management information associated withtarget functionality, and optionally perform actions with respect tothat management information. In one particular example, the managementsystem corresponds to functionality which allows the user to investigatethe configuration of the target functionality and modify theconfiguration. Certain examples in this disclosure are based on userinterface features commonly used in Microsoft Corporation's ManagementConsole (MMC); however, the principles described herein can be appliedto any kind of management system. For instance, another kind ofmanagement system can comprise any kind of functionality that “sits ontop” of a data store (e.g., a database) and is used by a user as a toolto interact with information stored in the data store. Broadly stated, amanagement system is any functionality that allows a user to interactwith data from one or more sources.

The term “management information” refers to any information which has abearing on the management of a computer system, including, but notlimited to, configuration information. That is, in the exemplary contextof a configuration application, the management information can pertainto configuration information which governs the operation of the computersystem. The configuration information can comprise various settings,security information, pointers, and so forth.

The term “target functionality” refers to any entity that is a “target”of the operations of the management system. Target functionality maycomprise one or more applications implemented by one or more computerunits.

The term “retrieval functionality” refers to any aspect of thetechnology used to retrieve information from a source (or sources)(e.g., from the target functionality), including specific retrievaltools/mechanisms, protocols, languages, and so forth.

The term “description language content” refers to any manner ofexpressing information in a declarative manner (e.g., by providingmarkup text which describes features of the management system), asopposed to the use of conventional computer instruction code. Thedescription language that is most commonly evoked in this discussion isthe Extensible Markup Language (XML).

As mentioned, the term “dialog-related user interface presentation” isused within this disclosure to encompass a wide array of user interfacepresentations designed to impart specific information to a user and/orto collect specific information from a user. One type of dialog-relateduser interface presentation comprises a tabbed user interfacepresentation that has multiple tabs used to invoke multiple respectivepages, any of which can be selected by a user at will. Another type ofdialog-related user interface presentation comprises a wizard-type userinterface presentation that presents multiple pages in a definedsequence. Many other kinds of dialog-related user interfacepresentations are possible. In the featured implementation, thedialog-related user interface presentation defines a supplemental userinterface presentation that can be invoked within the context of a mainuser interface presentation provided by a management system (as in theexample of the user interface presentation 404 of FIG. 4). However,other kinds of applications can deploy dialog related user interfacepresentations using the unique strategies described herein. Or acomputer system can provide these dialog-related user interfacepresentations in a “standalone” manner outside the context of anyapplication.

This disclosure includes the following sections. Section A presents anexemplary system that uses a management system to interact withmanagement information. Section B presents two flowcharts which describethe operation of the system of Section A. Section C describes anexemplary computer environment for implementing aspects of the system ofSection A. Section D sets forth examples of the system of Section A.

A. Exemplary System (FIGS. 5-9)

Generally, any of the functions described with reference to the figurescan be implemented using software, hardware (e.g., fixed logiccircuitry), manual processing, or a combination of theseimplementations. The term “logic, “module” or “functionality” as usedherein generally represents software, hardware, or a combination ofsoftware and hardware. For instance, in the case of a softwareimplementation, the terms “logic,” “module,” “functionality,” or“machine-readable code” represent any kind of program code or otherinstruction-based content that performs specified tasks when executed ona processing device or devices (e.g., CPU or CPUs). In the exemplary andnon-limiting case of a .NET-related implementation, code modules can beconfigured as managed code, unmanaged code, or a combination of managedand unmanaged code.

The program code can be stored in one or more machine readable memorydevices. More generally, the illustrated separation of logic, modulesand functionality into distinct units may reflect an actual physicalgrouping and allocation of such software and/or hardware, or cancorrespond to a conceptual allocation of different tasks performed by asingle software program and/or hardware unit. The illustrated logic,modules and functionality can be located at a single site (e.g., asimplemented by a processing device), or can be distributed over plurallocations.

A.1. Overview of the Management System

FIG. 5 shows a system 500 that includes a description language enabledmanagement system 502 (or simply a “management system” 502 henceforthfor brevity). The management system 502 provides management-relatedservices by combining declarative information specified in descriptionlanguage content (504, 506) with generic resources provided by genericresource content 508. The description language content (504, 506)effectively tailors (or adapts) the general purpose resources in thegeneric resource content 508 to implement specific management-relatedservices. A user 510 can thereby build the management system 502 bysimply creating description language content in a well structured andeasily understood manner, whereupon the description language contentwill invoke appropriately referenced generic resource content 508. Thisis in contrast to performing the potentially onerous and time-consumingtask of directly assembling code and user interface resources from“scratch” in an ad hoc and manual manner (as in the known approachespreviously described). Different applications of the management system502 also rely on the same core framework of generic resource content508, thus yielding a much more efficient strategy for building differentmanagement system applications compared to known approaches. Variousfeatures of the system 500 will be set forth in greater detail below.

By way of overview, the management system 502 interacts with targetfunctionality 512 via retrieval functionality 514 in the basic mannerset forth in connection with FIG. 1. More specifically, one exemplarypurpose of the management system 502 is to query the targetfunctionality 512 via the retrieval functionality 514 to extractmanagement information from one or more stores (not shown) provided bythe target functionality 512.

The target functionality 512 can represent one or more applicationsimplemented by a standalone computer unit, or a system comprisingmultiple computer units and/or other equipment (such as a server systemand associated data stores). Moreover, the target functionality 512 canbe implemented at a site which is local to or remote from the managementsystem 502. In the latter case, the management system 502 can interactwith the target functionality 512 via any kind (and any combination) ofcoupling mechanism, such as point-to-point coupling mechanism, localarea network, wide area network, and so forth. If implemented as anetwork interconnection, the coupling mechanism can rely on anycombination of hardwired or wireless links, various gateways, routers,and so forth.

In an environment that relies on a Windows™ operating system, theretrieval functionality 514 can rely on Windows ManagementInstrumentation (WMI) technology. Alternatively, or in addition, theretrieval functionality 514 can also rely on, in whole or in part,SQL-related technology, Active Directory technology, and so forth.Queries sent to the target functionality 512 can be configured todeclaratively specify where the sought-after management information isto be found, as well as the technology (or technologies) used toretrieve the management information.

As previously described, the user 510 can interact with the managementsystem 502 via a series of user interface presentations 516 provided ona display device 518 (such as a CRT device, LCD device, etc.), inconjunction with an input mechanism 520 (such as a keyboard, a touchscreen, a mouse-type pointing device, a joystick, and so forth).

The description language content (504, 506) can be expressed in a markuplanguage, such as the Extensible Markup Language (XML). XML is a subsetof the Standard Generalized Markup Language (SGML) that enablesdevelopers to create customized tags that describe the meaning of data,as opposed to the presentation of data. An XML document is composed ofXML elements, each of which includes a start tag (such as <Queries>), anend tag (such as </Queries>), and information between the two tags(which is referred to as the content of the elements). An element mayinclude any number (including zero) of name-value pairs (referred to asattributes) related by an equal sign that modifies certain features ofthe element (such as MONTH=“May”). Elements in an XML document can havea hierarchical relationship to each other that can be represented as adata tree. A so-called XML schema 522 provides a formal specificationthat defines the types of elements and the organization of elements thatshould appear in an XML document in order for that document to beconsidered so-called well formed.

In contrast, the generic resource content 508 can be expressed in amachine-readable code language, such as C#, Visual Basic.NET,JScript.NET, C++ with Managed Extensions, and so on. The resourcecontent 508 is specifically configured so that it can be “plugged into”different management system applications, as governed by descriptionlanguage information set forth in the description language content (504,506). Other generic resource content 508 provides general-purposebuilding blocks used to construct dialog-related user interfacepresentations (to be described).

In other words, the solution described herein involves extractingvariations in code resources and user interface resources from commonfeatures of the code resources and user interface resources, andexpressing the variations in a descriptive manner in the descriptionlanguage content (504, 506).

With the above introduction, it is possible to delve into the functionsprovided by the management system 502 in greater detail. The descriptionlanguage content (504, 506) includes two components. A first componentdefines console-related description language content 504. Theconsole-related description language content 504 provides descriptiveinformation which governs the building of the management system 502.Namely, a first aspect of this description language content 504, whencombined with appropriately referenced generic resource content 508,provides build functionality 524. The build functionality 524 performsthe core task of querying the target functionality 512 to extractmanagement information from appropriate stores. In the context of theMMC-type user interface presentation 200 shown in FIG. 2, the buildfunctionality 524 supplies the necessary management information toconstruct the nodes of the scope pane 202 and the detailed informationwithin the result pane 204.

A second aspect of the console-related description language content 504,when combined with appropriately referenced generic resource content508, provides presentation functionality 526. The presentationfunctionality 526 performs the core task of presenting the managementinformation that has been extracted by the build functionality 524. Inthe context of the MMC-type user interface presentation 200 shown inFIG. 2, the presentation functionality 526 provides the instructionswhich govern the manner in which the management information is displayedto a user. For example, the management system 502 can display the samemanagement information to a user in different formats, such as asimplified format and an expert format (and so forth). In this case, thepresentation functionality 526 governs the format used to present themanagement information. The presentation functionality 526 can alsospecify various particulars of the presentation, such as, for instance,by specifying the textual and iconic information which is presented toidentify different nodes in the scope pane 202 and the result pane 204,and so forth.

A third aspect of the console-related description language content 504,when combined with appropriately referenced generic resource content508, provides behavior functionality 528. The behavior functionality 528specifies the manner in which the user 510 is allowed to interact withthe management information that has been presented by the presentationfunctionality 526. Namely, the behavior functionality 528 can govern theaction options that are presented to the user 510, as well as the typesof operations which these actions respectively invoke. Consider theMMC-type user interface presentation shown in FIG. 3. In this case, thebehavior functionality 528 is used to govern the types of options thatare presented by the context menus (302, 304), as well as the types ofoperations which these options respectively invoke when selected.

On the other hand, a second component of the description languagecontent (504, 506) defines dialog-related description language content506. The dialog-related description language content 506 providesdescriptive information which, when combined with appropriatelyreferenced generic resource content 508, yields dialog functionality530. The purpose of the dialog functionality 530 is to provide the typesof supplemental user interface presentations shown in FIG. 4. Aspreviously stated, these types of displays are also generically referredto herein as “dialog-related user interface presentations.” Thedialog-related user interface presentations can be invoked when the user510 activates items within the context menus presented by the main userinterface presentation or when the user makes other appropriateselections in interacting with the management system 502.

More specifically, the dialog-related description language content 506provides descriptive information that governs the manner in whichgeneral purpose UI building blocks in the generic resource content 508are adapted to provide specific dialog-related user interfacepresentations. (However, the dialog-related description language content506 does not create the UI building blocks themselves from scratch, thisbeing the responsibility of other functionality which is not the topicof this disclosure.)

Exemplary and non-limiting different aspects of the description languagecontent 506 are enumerated as follows. A first aspect of this content506 allows the user 510 to specify a type of dialog-related userinterface presentation that is to be invoked. For instance, assume thatthe purpose of an exemplary dialog-related user interface presentationis to collect configuration information from the user 510 using acollection of user interface pages. The management system 502 canpotentially collect this information from the user 510 using differentUI paradigms (corresponding to different user interface “shells”). Forexample, in a first scenario, the management system 502 can provide adialog-related user interface presentation that provides the multiplepages to the user 510 in a tabbed arrangement, permitting the user 510to select any page in the collection of pages at will and in noparticular order (by activating an appropriate tab). In a secondscenario, the management system 502 can provide a dialog-related userinterface shell that presents the multiple pages in an ordered sequence,e.g., in a wizard-type format, thereby requiring the user 510 tosequence through the pages in a defined order. These are merelyillustrative examples, not exhaustive of the range of dialog-relateduser interface presentations that can be deployed. In any event, thefirst aspect of the dialog-related description language content 506specifies the type of display that is to be invoked by a particularmanagement system 502. Particular types of user interface shells andresources can be specified by providing ID information associated withthese shells and resources.

A second aspect of the dialog-related description language content 506allows the user 510 to specify the manner in which pages are arrangedwithin a particular dialog-related user interface shell. For example,assume that the management system 502 solicits information from the user510 using a wizard-type user interface presentation. The second aspectof the dialog-related description language content 506 can specify theorder of pages within the wizard-type presentation, and other relatedfeatures of the wizard-type presentation that affects its general designplan (e.g., by enabling or displaying branching within the wizard-typepresentation, and so forth). For example, the dialog-related descriptionlanguage content 506 can define a branch within a wizard thatcontingently depends on the user 510's input; for example, if the user510 selects a radio button B₁ in a wizard page P₁, then the wizard willdisplay a subsequent page P_(2-a), but if the user selects a radiobutton B₂ in the wizard page P₁, then the next page will be P_(2-b), andso forth. The content 506 can specifically define, in a declarativemanner, whether such branching is enabled or disabled, the nature ofevents which trigger the branching, the destinations of the branching(e.g., the “go to” pages), and so forth.

In one implementation, the content 506 can define the order of pageswithin a wizard by specifying such pages in a defined sequence withinthe content 506. Appendix D provides an example of XML content whichimplements a wizard having multiple pages to illustrate this feature.

A third aspect of the dialog-related description language content 506allows the user 510 to specify whether parts of the dialog-related userinterface presentation are to be enabled or disabled. In one scenario,the particular parts may correspond to whole pages within a multi-pagedialog-related user interface presentation. In another scenario, theparticular parts may correspond to fields within a single page. As willbe described, the decision to enable or disable parts of adialog-related user interface presentation can be contextual. Forinstance, a dialog-related user interface presentation may invoke aparticular part of its display when it is used in the context of a firsttool, but may not invoke the same part when it is used in the context ofa second tool. Recall that a tool being invoked corresponds to a nodewithin the scope pane. Hence, the context in which a tool is invoked isreflected by its corresponding node's relationship vis-a-vis its parentand ancestor nodes (if they exist) within the scope node tree. Parts ofa dialog-related user interface presentation that are disabled can beentirely omitted, “grayed out” (to indicate that they are inactive), orpresented (or not presented) in some other manner.

A fourth aspect of the dialog-related description language content 506allows the user 510 to specify default content which is presented in thedialog-related user interface presentation and/or default behavior whichis exhibited by the dialog-related user interface presentation. Namely,this aspect can be used to automatically populate the dialog-relateduser interface presentation with default information when it isinitially presented to the user 510, and/or when the user fails tomanually fill out prescribed fields in the dialog-related user interfacepresentation. Alternatively, or in addition, this aspect can be used tospecify whether certain user interface fields (such as various checkboxes, radio buttons, edit controls, etc.) are checked or unchecked.

A fifth aspect of the dialog-related description language content 506allows the user 510 to specify validation rules which govern the typesof input that the management system 502 will accept for different inputfields. Different rules may apply to different applications. Commonrules specify: (a) a maximum or minimum number of characters that can beinput; (b) permissible types of characters which can be input; (c)required fields of information that must be input (verses optionalfields); (d) permissible sequences of input operations, and so forth.Different mechanisms can be used to implement validation rules, such asa so-called regular expressions technique.

Later sections provide additional details regarding the above-summarizedfunctionalities (524, 526, 528, 530). Further, the Appendix (Section Dand associated FIGS. 13-25) provides examples of markup code that can beused to provide the description language content (504, 506) for onespecific and non-limiting application.

Continuing with the discussion of FIG. 5, this figure shows contentconstruction functionality 532. The content construction functionality532 is used to construct the description language content (504, 506). Inone implementation, the content construction functionality 532 cancomprise an editing-type program which is configured to facilitate thecreation of XML content (or other kind of description language content).For instance, the content construction functionality 532 can providevarious automated routines and other time-saving provisions for enteringXML content. The content construction functionality 532 can also providevarious error checking provisions which ensure that the XML contentobeys the schema(s) 522. In one case, a first schema defines the properconstruction of the console-related description language content 504,and a second schema defines the proper construction of thedialog-related description language content 506. As will be describedbelow in connection with FIGS. 8 and 9, company-specific anduser-specific schemas can also be provided which alter the masterschemas 522 in various respects to suit the requirements of local anduser environments.

It should be noted that the above-described functionalities (524, 526,528, 530) are shown as being deployed within the context of themanagement system 502, which is the preferred implementation set forthin this description. However, such functionalities (524, 526, 528, 530)can also be used in other applications (that is, in applications otherthan management and configuration-related applications). In other words,the unique combination of declarative content and generic resourcecontent can be used to simplify the programming of other applications.To name one example, the query-based build functionality 524 can be usedto interact with any repository of information, such as a SQL database.To name another example, the dialog functionality 530 can be used toprovide dialog-related user interface presentations (such as wizard-typepresentations) in the context of any application, including any kind ofhigh-end user application (such as a word processing programming, etc.),an operating system application, and so forth. Stated in another way,the user 510 can invoke the dialog functionality 530 outside the contextof the kind of MMC main user interface presentation 200 shown in FIG. 2.

In terms of physical implementation, the management system 502 can beimplemented as hardware and/or software implemented by any kind ofcomputer device, such as a personal computer device, personal digitalassistant (PDA) device, intelligent mobile phone device, any kind oftransportable or wearable computer device, any kind of game consoledevice (such as Microsoft Corporation's Xbox™ game consoles), and so on.Where the management system 502 is implemented by some kind of computerdevice, FIG. 12, to be discussed in turn, provides one exemplarycomputer environment for implementing the management system 502. Themanagement system 502 can be implemented in the same system thatimplements the target functionality 512, or the management system 502can be implemented in a system that is separate from (but coupled to)the target functionality 512.

FIG. 6 summarizes the concepts set forth above in the context of FIG. 5.As indicated in that figure, console-related description languagecontent 504 combines with generic resource content 508 to yielduniquely-tailored code that implements a number of activities. (In thiscontext, the generic resource content 508 represents multi-purpose codecontent that can be used to construct different management systemapplications.) A first activity (A) uses the description languagecontent 504 to populate the management information in the scope pane andthe result pane of the main user interface presentation (e.g., referback to FIG. 2 for an example of these panes). This activity cancomprise forwarding one or more queries to a management store maintainedby the target functionality 512. A second activity (B) uses thedescription language content 504 to govern the manner in which thethus-collected management information is presented to the user 510. Athird activity (C) governs the manner in which the user 510 is permittedto interact with the management information, and the types of operationswhich are invoked by the user 510's interaction.

On the other hand, dialog-related description language content 506combines with generic resource content 508 to yield uniquely-tailoreddialog-related user interface presentations. (In this context, thegeneric resource content 508 represents UI building blocks used toconstruct different dialog-related user interface presentations.) Thefourth activity (D) shown in FIG. 6 describes the creation of suchdialog-related user interface presentations.

For convenience of explanation, FIG. 6 illustrates the series ofactivities (A-D) as a chain performed in a defined sequence. But thisembodiment is merely exemplary. Different activities can be invoked bydifferent actions made by the user 510 in interacting with themanagement system 502; for this reason, the activities shown in FIG. 6can be performed in an order which differs from that shown in FIG. 6.

A.2. The Role of the Console-Related Description Language Content

With the above introduction, the following subsection providesadditional explanation regarding the console-related descriptionlanguage content 504. Generally, the console-related descriptionlanguage content 504 controls the building of the management system 502,and implements the build functionality 524, the presentationfunctionality 526, and the behavior functionality 528 of FIG. 5.

In connection with content 504, FIG. 7 shows a collection of nodes thatrepresents an excerpt of a hierarchical tree of nodes which populate ascope pane (e.g., as in the case of the scope pane 202 of FIG. 2's mainuser interface presentation 200). The collection of nodes has a rootnode 702. Other nodes that depend from the root node 702 define childnodes 704. That is, for example, node 706 is a child of root node 702(e.g., root node 702 being its parent). Child node 706, in turn,includes other child nodes which depend from it. In the context of atypical management system 502, the nodes may represent tools or otheraccess portals that the user 510 can activate so as to interact withmanagement information maintained by the target functionality 512.

In one exemplary case, the content construction functionality 532 can beemployed to create the console-related description language content 504on a node-by-node basis. In other words, the user 510 can define theconsole-related description language content 504 by creatingcorresponding markup content for each respective tool or portalrepresented by the scope pane. In this implementation, the contentconstruction functionality 532 can supply a prescribed set ofdeclarative information items for each node. FIG. 7 enumerates oneexemplary and non-limiting set of information items that can beassociated with each node. Each item of this exemplary set is explainedbelow.

Name. The name information provides a name associated with the nodewhich is conveyed to the user 510 via the management system userinterface presentation.

Description. The description information provides a descriptionassociated with the node which is conveyed to the user 510.

Node Assembly. The Node Assembly information provides a pointer toexecutable code content which can be invoked in association with thenode. For example, this assembly information can be invoked when theuser clicks on a node, for instance, to expand the contents of the node.This approach to populating management information can be used as areplacement for query-driven management information retrieval, or tosupplement query-driven management information retrieval. For instance,this mechanism can be used when query-driven retrieval becomes toocomplex to describe in markup. In addition to populating the data, theaccessed assembly code can process the input data fed to the code and/orprocess the output data supplied by the code.

Node View Assembly. The Node View Assembly information governs themanner in which various information associated with the node ispresented to the user 510. More specifically, the View Assembly definesthe manner in which the data accessed by a query (or by other means) ispresented in the result pane (e.g., in graphical format, text-basedformat, spreadsheet-based format, and so on). To perform this function,the View Assembly identifies a pointer to code that can be invoked toprovide the desired presentation of the data.

GUID. The GUID information defines an ID which is assigned to the nodeto uniquely identify the node. In an MMC context, the GUID informationcan be used by developers to “extend” the functionality of theadministration console using externally loaded code.

Queries. The query information defines queries that are invoked by thenode to retrieve management information from the target functionality512.

Menu Handler Definition. The menu handler definition information governsthe type of options that are presented in context menus, and thecorresponding types of operations which are invoked by the options.

The above-identified set of descriptive content items is merelyexemplary. Other applications can provide additional items, or can omitone or more items shown in FIG. 7. In any event, as will be described inconnection with FIGS. 13-19 in Section D (below), the console-relateddescription language content 504 can demarcate the above-identifieddescriptive content items using appropriate markup tags.

As previously described, a node's characteristics may be contextual,meaning that attributes of a child node may derive, in part, from thatnode's parent node or an ancestor node. For instance, the node 706depends from the node 702, and therefore may inherit attributesassociated with node 702. In effect, this means that a query performedwith respect to a parent or ancestor node may act so as to populateattribute information for one or more child nodes. For example, considerthe case of the menu handler definition item. When displaying a contextmenu associated with node 706, the management system 502 can displayoptions which locally derive from node 706, as well as options whichdrive from parent node 702. In other words, the context menu presentedfor a particular node may depend on the overriding context in which thisnode (and associated tool) is being employed.

Further, the types of queries that are performed by a node may depend onthe node's position within the hierarchy of nodes. As enumerated in FIG.7, a node may enable two kinds of queries to supply managementinformation to populate the scope pane, and enable another two kinds ofqueries to supply management information for the result pane. In each ofthese categories, one query is enabled for the case in which thecorresponding node is “unscoped” (meaning that it has no parent withinthe tree of nodes that affects the query). Another query is enabled forthe case in which the corresponding node is “scoped” (meaning that ithas a parent within the tree of nodes that affects the query).

For example, a root node has no parent. Consequently, a query executedon this node to populate its children will constitute an unscoped query.After this operation, each of the child nodes associated with the rootnode will have a parent (i.e., the root node). Consequently, a queryexecuted on a child node to populate its own children will constitute ascoped query (because the query takes place in the context of theoverriding scope of the root node). For example, in a File Explorerapplication, when the user clicks the c drive (root), a query is run toretrieve the files and folders in the root of (c: ). This constitutes anunscoped query. But when the user then clicks on a folder in the root,another query is run which returns the files/folders under the selectedfolder. This constitutes a query which is scoped to the selected folder.

Again, the Appendix to this disclosure (in Section D) provides specificexamples which demonstrate how the console-related description languagecontent 504 can be implemented in XML.

A.3. Modification of Schemas and Templates to Suit Local and UserEnvironments

FIG. 8 illustrates a manner in which a master schema can be modified tosuit various local and user environments. Namely, a product developercan define a master schema 802 which provides a general purpose schemathat governs the building of the management system 502 in anyenvironment. However, different organizations (e.g., differentcompanies) may have particular requirements which make certain aspectsof the general purpose schema 802 appropriate and other aspectsinappropriate. For instance, because of a convention followed by aparticular company, that company may mandate that certain managementinformation by collected in a prescribed way, displayed in a prescribedway, and/or interfaced with in a prescribed way. To this end, anadministrator of the company can modify the general purpose schema 802to provide a local setting schema 804 that applies within the localenvironment. In the same manner, an individual user (or group of users)can further tailor the master schema 802 to suit their unique needs andpreferences, to yield a user-specific schema 806.

In an analogous manner, FIG. 9 illustrates how a master user interfacetemplate can be modified to suit various local environments. Namely, aproduct developer can define a master user interface template 902 whichsets forth general aspects of a dialog-related user interfacepresentation. A company administrator can modify the general purposeuser interface template 902 to provide a local setting template 904 thatapplies within the local environment. In a similar manner, an individualuser (or group of users) can further tailor the maser UI template 902 tosuit their particular needs and preferences, to yield a user-specific UItemplate 906.

B. Exemplary Method of Operation (FIGS. 10 and 11)

FIGS. 10 and 11 together describe procedural aspects of the managementsystem 502 set forth in FIG. 5. To facilitate discussion, certainoperations are described as constituting distinct steps performed in acertain order. Such implementations are exemplary and non-limiting.Certain steps described herein can be grouped together and performed ina single operation, and certain steps can be performed in an order thatdiffers from the order employed in the examples set forth in thisdisclosure. As the functions performed by the management system 502 havebeen fully explained in prior sections, this section will serveprimarily as a review of those functions.

In a procedure 1000 of FIG. 10, a first step 1002 entails creating theconsole-related description language content 504. As described,descriptive XML-based content 504 governs the building of the managementsystem (MS). A second step 1004 entails creating dialog-relateddescription language content 506. This content 506 governs the buildingof the dialog-related user interface presentations. Different schemasmay constraint the development of the console-related descriptionlanguage content 504 and the dialog-related description language content506.

In a procedure 1100 shown in FIG. 11, a first step 1102 pertains toinvocation of the management system (MS) 502 by the user 510. A secondstep 1104 pertains to building the management system 502 using the buildfunctionality 524, which prompts the retrieval functionality 514 toretrieve management information from the target functionality 512. Thesecond step 1104 also involves presenting the retrieved managementinformation using the presentation functionality 526. The second step1104 also involves governing the behavior of the user 510's interactionwith the management information using the behavior functionality 528. Athird step 1106 involves proving dialog-related user interfacepresentations (e.g., multi-tabbed user interface presentations orwizard-type user interface presentations, and so forth) based on thedialog functionality 530. The steps in the procedure 1100 are shown asbeing performed in a particular order only to facilitate discussion. Inan actual application, the management console 502 may repeat the stepsshown in FIG. 11 many times throughout a session in an arbitrary orderdepending on the user 51O's actions.

C. Exemplary Computer Environment (FIG. 12)

In one exemplary implementation, certain aspects of the managementsystem 502 can be implemented as computer code executed by one or morecomputer devices. In this case, FIG. 12 provides information regardingan exemplary computer environment 1200 that can be used to implementeach such computer devices.

The computing environment 1200 includes a general purpose or server typecomputer 1202 and a display device 1204. However, the computingenvironment 1200 can include other kinds of computing equipment. Forexample, although not shown, the computer environment 1200 can includehand-held or laptop devices, set top boxes, game consoles, mainframecomputers, etc. Further, FIG. 12 shows elements of the computerenvironment 1200 grouped together to facilitate discussion. However, thecomputing environment 1200 can employ a distributed processingconfiguration. In a distributed computing environment, computingresources can be physically dispersed throughout the environment.

Exemplary computer 1202 includes one or more processors or processingunits 1206, a system memory 1208, and a bus 1210. The bus 1210 connectsvarious system components together. For instance, the bus 1210 connectsthe processor 1206 to the system memory 1208. The bus 1210 can beimplemented using any kind of bus structure or combination of busstructures, including a memory bus or memory controller, a peripheralbus, an accelerated graphics port, and a processor or local bus usingany of a variety of bus architectures.

Computer 1202 can also include a variety of computer readable media,including a variety of types of volatile and non-volatile media, each ofwhich can be removable or non-removable. For example, system memory 1208includes computer readable media in the form of volatile memory, such asrandom access memory (RAM) 1212, and non-volatile memory, such as readonly memory (ROM) 1214. ROM 1214 includes an input/output system (BIOS)1216 that contains the basic routines that help to transfer informationbetween elements within computer 1202, such as during start-up. RAM 1212typically contains data and/or program modules in a form that can bequickly accessed by processing unit 1206.

Other kinds of computer storage media include a hard disk drive 1218 forreading from and writing to a non-removable, non-volatile magneticmedia, a magnetic disk drive 1220 for reading from and writing to aremovable, non-volatile magnetic disk 1222 (e.g., a “floppy disk”), andan optical disk drive 1224 for reading from and/or writing to aremovable, non-volatile optical disk 1226 such as a CD-ROM, DVD-ROM, orother optical media. The hard disk drive 1218, magnetic disk drive 1220,and optical disk drive 1224 are each connected to the system bus 1210 byone or more data media interfaces 1228. Alternatively, the hard diskdrive 1218, magnetic disk drive 1220, and optical disk drive 1224 can beconnected to the system bus 1210 by a SCSI interface (not shown), orother coupling mechanism. Although not shown, the computer 1202 caninclude other types of computer readable media, such as magneticcassettes or other magnetic storage devices, flash memory cards, CD-ROM,digital versatile disks (DVD) or other optical storage, electricallyerasable programmable read-only memory (EEPROM), etc.

Generally, the above-identified computer readable media providenon-volatile storage of computer readable instructions, data structures,program modules, and other data for use by computer 1202. For instance,the readable media can store the operating system 1230,application-specific functionality 1232 (including functionality forimplementing aspects of the management system 502), other programmodules 1234, and program data 1236.

The computer environment 1200 can include a variety of input devices.For instance, the computer environment 1200 includes the keyboard 1238and a pointing device 1240 (e.g., a “mouse”) for entering commands andinformation into computer 1202. The computer environment 1200 caninclude other input devices (not illustrated), such as a microphone,joystick, game pad, satellite dish, serial port, scanner, card readingdevices, digital or video camera, etc. Input/output interfaces 1242couple the input devices to the processing unit 1206. More generally,input devices can be coupled to the computer 1202 through any kind ofinterface and bus structures, such as a parallel port, serial port, gameport, universal serial bus (USB) port, etc.

The computer environment 1200 also includes the display device 1204. Avideo adapter 1244 couples the display device 1204 to the bus 1210. Inaddition to the display device 1204, the computer environment 1200 caninclude other output peripheral devices, such as speakers (not shown), aprinter (not shown), etc.

Computer 1202 operates in a networked environment using logicalconnections to one or more remote computers, such as a remote computingdevice 1246. The remote computing device 1246 can comprise any kind ofcomputer equipment, including a general purpose personal computer,portable computer, a server, etc. Remote computing device 1246 caninclude all of the features discussed above with respect to computer1202, or some subset thereof.

Any type of network 1248 can be used to couple the computer 1202 withremote computing device 1246, such as the WAN 402 of FIG. 4, a LAN, etc.The computer 1202 couples to the network 1248 via network interface 1250(e.g., the interface 416 shown in FIG. 4), which can utilize broadbandconnectivity, modem connectivity, DSL connectivity, or other connectionstrategy. Although not illustrated, the computing environment 1200 canprovide wireless communication functionality for connecting computer1202 with remote computing device 1246 (e.g., via modulated radiosignals, modulated infrared signals, etc.).

The above-described computer 1202 can use the management system 502 tomanage a target functionality 512 implemented by the computer 702 itself(e.g., where the target functionality 512 may represent a collection ofresources maintained by the computer 702). Or the computer can use themanagement system 502 to manage a target functionality 512 implementedby some remote system, e.g., accessible via network 1248 or some othercoupling mechanism.

D. Appendix: Examples (FIGS. 13-25)

FIGS. 13-25 provide examples of description language content (504, 506)and user interface presentations associated with the content.

D.1. Exemplary Management Console XML and Associated UI Presentations

To begin with, FIG. 13 shows a main user interface presentation 1300provided by the management system 502. The main user interfacepresentation 1300 includes a scope pane 1302 and a result pane 1304. Inthis particular example, the user 510 has selected the root node 1306 inthe scope pane 1304, whereupon the management system 502 providescorresponding detail in the result pane 1304.

The root node 1306 includes a plurality of child nodes 1308, including aCollections node 1310. Assume that the user 510 selects the Collectionsnode 1310 (e.g., by clicking on the Collections node 1310 in the scopepane 1302. This prompts the management system 502 to present the userinterface presentation 1400 shown in FIG. 14. The scope pane 1302 ofthis user interface presentation 1400 enumerates a collection of childnodes 1402 associated with the collection node 1310. The result pane1304 shows data corresponding to the child nodes 1402.

FIGS. 15-19 show an exemplary console-related description languagecontent 504 that defines the information presented in the user interfacepresentation 1400. Note that the XML content in the console-relateddescription language content 504 includes many of the elements definedin connection with FIG. 7. The particular XML elements in these figuresare demarcated by descriptive tags associated with the elements(identified by the conventional XML “< . . . > . . . </ . . . >”notation). Several of these elements are described below.

<Name>. The Name element identifies a name associated with an identifiednode that is displayed in the scope pane 1302 (e.g., in this case, theCollections node 1310).

<Description>. The Description element identifies descriptiveinformation that is presented by the user interface presentation 1400upon selection of an identified node.

<Guid>. The Guid element provides a unique identifier that identifies anode. For instance, the Guid provide a reference that allows thirdparties to associate tools with the node.

<ImagesDetails>. The ImagesDetails element provides information thatidentifies what kind of image information is presented in the scope pane1302 for an identified node (for a selected state in which the node hasbeen selected, and for an unselected state in which the node has notbeen selected).

<ViewAssemblylmageDetails>. The ViewAssemblylmageDetails element governsthe manner in which data associated with an identified node is presentedin the user interface presentation 1400. Possible modes of displayinclude graphical type presentation, tabular type presentation, textualtype presentation, spreadsheet type presentation, and so on.

<ClipboardFormats>. The ClipboardFormats element specifies a format thatapplies when information is “dragged” to an identified node.

<Actions>. The Actions element specifies what menu(s) are presented (andin what order the menus are presented) when the user 510 right-clicks onan identified node.

<Query> related tags. Various query-related elements govern the mannerin which the management system 502 executes queries to retrieveinformation from the target functionality 512. For example, a<QueryDetail> element (e.g., element 1602 in FIG. 16) specifies a typeof query that should be executed. Namely, this element can invokeparticular retrieval functionality 514 (e.g., WQL retrievalfunctionality) for accessing information from the target functionality512.

As to the queries themselves, the XML description shown in FIGS. 15-19specifies four queries, corresponding to the four enumerated queriessummarized above in the context of FIG. 7. To begin with, the query 1604shown in FIG. 16 populates the child nodes 1402 in the scope pane 1302when the user clicks on the Collections node 1310. More specifically,for instance, the query 1604 retrieves various fields of information,including name information. Such name information “plugs into” the Nameelement 1606 shown in FIG. 16, to provide name information associatedwith the child nodes 1402 of the Collections node 1310. The next query1702 in FIG. 17 populates the result pane 1304 with data based on theselection of the Collections node 1310. The first two queries (1604,1702) correspond to so-called unscoped queries, as these retrievaloperations are not governed by a context established by a parent node.

In contrast, query 1802 shown in FIG. 18 corresponds to a scoped query.The query 1802 is scoped in the sense that it is defined by a contextestablished by a parent node, in this case, the Collections node 1310.More precisely, query 1802 is invoked, for example, when the user 510clicks on one of the child nodes 1402 associated with the Collectionsnode 1310, such as the exemplary “All User Groups” child node 1404. Thisaction effectively fills out the CollectionID field enclosed in bracketswithin the query 1802, and also causes the management system 502 toexpand the scope pane 1302 by displaying the child nodes (not shown) ofthe All User Group node 1404. A final scoped query 1902 in FIG. 19populates the result pane 1304 for a selected scoped node (such as theAll User Groups node 1404).

A node need not include each of the queries enumerated above. Forexample, a node may include only a result pane query used to populatethe result pane 1304. Indeed, a node need not execute any query; in thiscase, the XML content 504 can itself be used to specify the behavior ofthe management system 502 when the user 510 clicks on a query-less node(e.g., by providing child information to populate a subtree, etc.).

Still alternatively, a node can implement one or more queries in code,and the XML context 504 can serve the purpose of pointing to this codeso that it can be accessed when the user 510 selects a correspondingnode.

D.2. Exemplary User Interface XML and Associated UI Presentations

FIGS. 20 and 21 show exemplary dialog-related user interfacepresentations (2000, 2100) produced by the management system 502, basedon dialog-related description language content 506. Namely, FIG. 20shows a first rendition of a dialog-related user interface presentation2000 that uses a wizard paradigm to combine multiple pages together. Asmentioned earlier, a wizard provides a sequence of pages through whichthe user 510 can sequence in a defined order; FIG. 20 shows just one ofthe pages in this sequence. FIG. 21 shows a second rendition of adialog-related user interface presentation 2100 that uses a tabbedparadigm to combine multiple pages together. A tabbed presentationallows a user to select any page at any time from a collection of tabsthat are typically accessible to each page (e.g., in the case of FIG.21, the tabs are presented at the top of each page); FIG. 21 shows justone of the tabbed pages.

FIGS. 22-25 show exemplary dialog-related description language content506 that defines salient aspects of the dialog-related user interfacepresentations (2000, 2100). More specifically, the dialog-relateddescription language content 506 defines how predefined user interfacebuilding blocks can be customized in various respects to a suit aparticular application. For instance, the customization may pertain tothe selection of a particular type of dialog-related user interfacepresentation and the arrangement of its constituent parts. Thecustomization may also specify how the dialog-related user interfacepresentation is filled out. For instance, the customization can definedefault information that is presented in the dialog-related userinterface presentation. The customization can also define rules used tovalidate information that is input into the dialog-related userinterface presentation. Still other facets of the dialog-related userinterface presentation can be defined via the dialog-related descriptionlanguage content 506. In one implementation, however, the purpose of thedialog-related description language content 506 is not to specify thecomposition of the UI features that appear in the dialog-related userinterface presentation from “scratch”; rather, these UI features areprovided as pre-existing building blocks (in the generic resourcelibrary 508) that are selected, customized and assembled by thedialog-related description language content 506.

Note that the XML content in FIGS. 22-25 includes many of the elementsdefined in previous sections of this disclosure. The particular XMLelements in these figures are demarcated by descriptive tags associatedwith the elements (identified by the conventional XML “< . . . > . . .</ . . . >” notation). Several of these elements are described below.

Tags defining the type of presentation. An introductory section 2202 ofthe dialog-related description language content 506 specifies the basicframework of the dialog-related user interface presentation that is tobe presented, e.g., by identifying its GUID, assembly name, etc. Somedialog-related user interface presentations can be formulated as eitherwizards or as tabbed presentations. An IsWizard definition 2204specifies whether the presentation will be configured as a wizard ortabbed presentation. That is, the IsWizard field 2204 can define whetherthe content 506 renders the wizard display of FIG. 20 or the tabbeddisplay of FIG. 21. In the illustrated example, this field specifiesthat IsWizard=“True,” meaning that a wizard-type format is being used.

Information defining the manner of presentation of user interface parts.The dialog-related user interface presentation can include one or morepages. The XML content that follows the introductory section 2202specifies the manner in which the parts of the dialog-related userinterface presentation are combined together. Namely, a <PropertyPageGuid> tag demarcates the start of each page in the multi-page userinterface presentation. As illustrated, the XML content in FIGS. 22-25describes each page in sequence. This sequence defines an order in whichpages will be presented. For instance, if the wizard-type format isselected, the order of page descriptions in the XML content defines theorder in which corresponding pages will appear in the wizard. Moreover,a “Skippable” field (e.g., field 2206) associated with each page defineswhether that page is invoked in the wizard presentation. Thus, a“Skippable=False” definition indicates that the management system 502will present an associated page, while a “Skippable=True” definitionindicates that the management system 502 will not present the associatedpage. In the described implementation, the management system 502 simplydoes not display a page that is skipped over; but in alternativeimplementation, the Skippable field can determine whether or not theend-user is independently empowered to deactivate or skip over a pagewithin the multi-part presentation. Through this provision, the designer(or the end-user) can easily toggle pages into or out of adialog-related user interface presentation to suit the demands ofindividual applications and environments, all without modifying the codeitself.

Help information. A HelpTopic field (e.g., field 2208) defines thehelp-related information that is presented for each page in thepresentation.

Default information. The XML content 506 also defines what informationis populated in the user interface pages as a default. For instance, thedefault information may specify what information is automatically filledin when the user first visits a page, or may alternatively specify whatinformation is automatically filled in only in the event that the userleaves a page without filling in certain fields. Consider, for example,a Name input field 2002 shown in FIG. 20. The XML content 506, by virtueof the DefaultValue field 2210 in FIG. 22, specifies that this page ofthe wizard will automatically populate the Name field with the value“Pkg.” A DefaultValue=“ ” definition indicates that the managementsystem will populate no default information in a corresponding userinterface field. The particular default definitions shown in FIGS. 22-25are exemplary. Those skilled in the art will appreciate that any aspectof the user interface presentation can be defined via defaultinformation contained in the XML content 506.

Validation information. The XML content 506 also defines the rules whichgovern what information an end-user is permitted to input via thedialog-related user interface presentation. For example, again considerthe exemplary Name input field 2002 shown in FIG. 20. The XML content506 includes a portion 2212 that declaratively defines the rules whichgovern what information an end-user can input into the Name field 2002.More specifically, MinLength and MaxLength fields define the minimum andmaximum number of characters that constrain a permissible inputresponse. A <MustMatchPatterns> series of rules defines content thatmust appear in the user's response, while a <MustNotMatchPatterns>series of rules defines content that must not appear in the user'sresponse. Any kind of constraint can be invoked by these positive andnegative rules. In a typical scenario, these rules which specify thekinds of alpha-numeric characters that can be received via an inputfield, for example, mandating that only alphabetical characters beinput, only numeric characters be input, only upper case letters beinput, only lower case letters be input, and so forth. In addition, therules can become more complex, e.g., by mandating that certaincharacters in a sequence meet predetermined criteria, or even providingconditional-type rules (e.g., if a character is a period “.” then thenext character should be an uppercase alphabetical character), and soforth. One way of implementing the positive and negative validationrules is via regular expression technology. In this approach, a regularexpression definition specifies the permissible format that constrains auser's input response. A regular expression engine then accepts a user'sactual response and compares it to the permitted response, returning anindication of whether the user's response meets the positive andnegative rules set forth in the permitted response. The exemplaryportion 2212 shown in FIG. 22 specifies that RegEx=“”, meaning that anylegal alphanumeric character can be input (providing that it is at least1 character and no greater than 35 characters, which is a constraintimposed by the MinLength and MaxLength fields). The particularvalidation constraints shown in FIGS. 22-25 are exemplary. Those skilledin the art will appreciate that any aspect of the user interfacepresentation can be constrained via the validation information containedin the XML content 506.

More generally, the specific elements and organization of elementsdescribed in this Appendix are illustrative and non-limiting. Thoseskilled in the art will appreciate that other declarative-basedstrategies exist for implementing the general principles set forthherein.

More generally, although the invention has been described in languagespecific to structural features and/or methodological acts, it is to beunderstood that the invention defined in the appended claims is notnecessarily limited to the specific features or acts described. Rather,the specific features and acts are disclosed as exemplary forms ofimplementing the claimed invention.

1. A system for providing a user interface presentation, comprising:description language content which describes at least one aspect of theuser interface presentation; generic resource content for providing atleast one resource used to construct the user interface presentation;and functionality for providing the user interface presentation bycombining the description language content and the generic resourcecontent, wherein the description language content tailors the genericresource content to provide the user interface presentation.
 2. Thesystem of claim 1, wherein the system comprises a management systemconfigured to interact with management information stored in amanagement information source, and wherein the user interfacepresentation is configured to facilitate such interaction.
 3. The systemof claim 2, wherein the system is configured to provide a context menuwhen a user interacts with the management system, wherein the managementsystem is configured to provide the user interface presentation when theuser selects an option within the context menu.
 4. The system of claim1, wherein the description language content is expressed in a markuplanguage.
 5. The system of claim 4, wherein the markup language isExtensible Markup Language (XML).
 6. The system of claim 1, wherein saidat least one aspect described by the description language governs a typeof the of the user interface presentation that is being deployed.
 7. Thesystem of claim 1, wherein said at least one aspect described by thedescription language governs a manner of arranging multiple parts of theuser interface presentation.
 8. The system of claim 7, wherein themultiple parts correspond to multiple pages, and wherein one manner ofarranging pages allows the multiple pages to be accessed by a user inany order.
 9. The system of claim 7, wherein the multiple partscorrespond to multiple pages, and wherein one manner of arranging pagesallows the multiple pages to be accessed by a user in an order definedby a wizard-type presentation.
 10. The system of claim 7, wherein thedescription language specifies branching rules used to navigate amongthe multiple parts during use.
 11. The system of claim 1, wherein saidat least one aspect described by the description language governswhether a part of the user interface presentation is provided or notprovided.
 12. The system of claim 1, wherein said at least one aspectdescribed by the description language governs default information whichis presented in the user interface presentation.
 13. The system of claim1, wherein said at least one aspect described by the descriptionlanguage governs a manner in which information input by a user into theuser interface application is validated.
 14. The system of claim 13,wherein regular expression technology is used to validate theinformation input by the user.
 15. The system of claim 13, wherein themanner in which information is validated comprises ensuring that theuser's input contains required first information, and/or ensuring thatthe user's input does not contain prohibited second content.
 16. Thesystem of claim 13, wherein the manner in which information is validatedcomprises ensuring that the user's input has a permitted number ofcharacters.
 17. The system of claim 1, wherein the description languagecontent is based on a template, wherein the template comprises at leastone of: a master template; an organization-specific template whichmodifies the master template for use within the organization; or auser-specific template which modifies the master template for use by oneor more users.
 18. One or more machine-readable media containing machinereadable instructions for implementing the system of claim
 1. 19. Asystem for providing a user interface application, comprising:description language content, including: first description languagecontent which governs a type of the user interface presentation that isbeing deployed; second description language content which governs amanner of arranging multiple parts of the user interface presentation;third description language content which governs whether parts of theuser interface presentation are enabled or disabled; fourth descriptionlanguage content which governs default information which is presented inthe user interface presentation; and fifth description language contentwhich governs a manner in which information input by a user into theuser interface presentation is validated; generic resource content forproviding at least one resource used to construct the user interfacepresentation; and functionality for providing the user interfacepresentation by combining the description language content and thegeneric resource content, wherein the description language contenttailors the generic resource content to provide the user interfacepresentation.
 20. A method for providing a user interface presentation,comprising: providing description language content which describes atleast one aspect of the user interface presentation; providing genericresource content that supplies at least one resource used to constructthe user interface presentation; and implementing the user interfacepresentation by combining the description language content and thegeneric resource content, wherein the description language contenttailors the generic resource content to a specific configuration toprovide the user interface presentation.